Dans le sillage de la porte dérobée dans le projet XZ Utils, la question était posée : d’autres projets open source étaient-ils concernés par ce type de manœuvre ? Dans une communication du 15 avril, les fondations Open Source Security et OpenJS répondent par l’affirmative, au moins trois projets JavaScript ayant été ciblés par des individus non identifiés.
L’affaire XZ Utils a fait beaucoup de bruit. Imaginez : un projet open source, une brique essentielle de l’environnement Linux et, plus généralement, de l’infrastructure d’Internet, un nouveau mainteneur providentiel, des modifications semblant légitimes, une porte dérobée en embuscade, une découverte presque par hasard par un ingénieur de Microsoft, une réaction rapide de la communauté et des éditeurs de distribution…
Que l’on puisse introduire aussi « facilement » une porte dérobée dans une brique aussi importante avait de quoi susciter bien des interrogations. Dont la principale : d’autres projets étaient-ils concernés ? La question a rapidement tourné dans les conversations. D’autant que dans le cas de XZ Utils, les signes pointaient sur une organisation digne d’une attaque soutenue par un État (APT, pour Advanced persistent threat), car témoignant d’une planification sur au moins deux ans.
Il n’aura pas fallu longtemps pour trouver d’autres signes de compromission. C’est le message adressé par les fondations Open Source Security (OpenSSF) et OpenJS aux développeurs, appelés à faire preuve de vigilance sur les sources des modifications dans les projets.
Au moins trois projets JavaScript concernés
Abonnez-vous pour tout dévorer et ne rien manquer.
Déjà abonné ? Se connecter
Commentaires (16)
#1
#2
#2.1
Eh bien je te remercie de la précision car, comme tu le soulignes, cette expression "santé mentale" je l'avais mal comprise dans les articles précédents!
#2.2
Visiblement, il souffre de dépression et / ou de burn out avec des retraits réguliers d’internet.
Et ça serait bien qu’on arrête de considérer négativement les maladies mentales, ca permettrait qu’elles soient mieux traitées !
Historique des modifications :
Posté le 17/04/2024 à 21h34
Lasse a bien utilisé le terme « longterm mental health issues » et à noter qu’il est de Finlande et non d’Amérique du Nord.
Visiblement, il souffre de dépression et / ou de burn out avec des retraits réguliers d’internet.
Et ça serait bien qu’on arrête de considérer négativement les maladies mentales, ca permettrait qu’elles soient mieux traitées !
#3
#4
Historique des modifications :
Posté le 17/04/2024 à 20h41
À ce propos, je partage ce bon article de blog du créateur/mainteneur de Curl, Daniel Stenberg : https://daniel.haxx.se/blog/2024/04/10/verified-curl/
#5
#5.1
Phrase dans la source :
#5.3
Et oui, comme le dit Furanku plus bas, obscurcie est bien en référence à obscurcissement, la traduction d'obfuscation utilisé en anglais.
#5.2
Je n'ai pas très bien compris le sens du terme non plus.
Edit : grilled.
Historique des modifications :
Posté le 18/04/2024 à 10h05
De l'obfuscation peut-être ? Ou des techniques pour noyer le poisson dans une PR conséquente (j'opterais plus pour cette seconde option) ?
Je n'ai pas très bien compris le sens du terme non plus.
Edit : grilled.
#5.4
#6
- se baser sur les archives venant réellement du code source et non d’archives mises à dispo du mainteneur,
- des sécurités sur la compilation dont des générations d’erreurs au lieu d’ignorer certaines choses (le cas du point ajouté juste après l’entête…)
- sécurisation de systemd…
Pas mal de détails sont dispo ici (en anglais)
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Le logiciel propriétaire n’est pas du tout à l’abris de ce genre de problème d’autant plus qu’il se base de plus en plus sur des briques libres sans forcément contribuer aux briques en question…
Et pour l’installation de trucs, zarb à l’insu des personnes, que dire de l’installation de copilot sur du windows server ? Microsoft vient d’indiquer que « oups » c’est une erreur… :
https://www.bleepingcomputer.com/news/microsoft/microsoft-copilot-app-on-windows-server-mistakenly-added-by-edge/
#7
Et pour illustrer le dessin de xkcd, le projet openSSL (qui a eu une influence déterminante sur le développement d'internet en permettant des communications sécurisées) n'était maintenu que par un seul développeur à plein temps au moment de l'apparition de la vulnérabilité HeartBleed.
#7.1
#7.2
Généralement, les entreprises vont vouloir prendre un produit vendu par un éditeur tout simplement pour le support. Même si celui-ci est ridiculement inutile, inefficace, coûteux, et que les équipes internes du client sont 100x plus compétentes que le chatbot scripté du support.
Mais ce qui motive surtout, c'est forcément la contractualisation, donc le juridique. Signer avec un éditeur, quand on lit ses contrats évidemment, c'est aussi chercher à avoir des garanties ou des engagements avec potentiellement matière à exiger des contreparties en cas de problème. Chose qu'on a pas avec un produit open source puisque c'est livré en l'état et demerden sie sich. C'est aussi notamment pour ça que le SaaS a percé en entreprise et que nombre des solutions métier le sont désormais (ITSM, RH, comptabilité, bureautique, etc).
Quand bien même les produits SaaS soient des vieux monolithes historiques moisis Cloudifiés à la truelle bourrés de faille. Genre Atlassian qui passe pas un trimestre sans avoir une news sur une faille critique sur les versions on-premise de leurs produits. Moi ça me rassure pas sur leur Claude.
Historique des modifications :
Posté le 18/04/2024 à 20h53
Entre l'open source et le propriétaire, pour moi il n'y a qu'une seule différence : le juridique.
Généralement, les entreprises vont vouloir prendre un produit vendu par un éditeur tout simplement pour le support. Même si celui-ci est ridiculement inutile, inefficace, coûteux, et que les équipes internes du client sont 100x plus compétentes que le chatbot scripté du support.
Mais ce qui motive surtout, c'est forcément la contractualisation, donc le juridique. Signer avec un éditeur, quand on lit ses contrats évidemment, c'est aussi chercher à avoir des garanties ou des engagements avec potentiellement matière à exiger des contreparties en cas de problème. Chose qu'on a pas avec un produit open source puisque c'est livré en l'état et demerden sie sich. C'est aussi notamment pour ça que le SaaS a percé en entreprise et que nombre des solutions métier le sont désormais (ITSM, RH, comptabilité, bureautique, etc).
Quand bien même les produits SaaS soient des vieux monolithes historiques moisis Cloudifiés à la truelle bourrés de faille. Genre Atlassian qui passe pas un trimestre sans avoir une news sur une faille critique.
#8
Historique des modifications :
Posté le 23/04/2024 à 20h17
C'est Pavel Durov, patron de Telegram, qui racontait dans une interview récente à 18:15 entre autres infos hallucinantes (c'est une entreprise de 30 ingénieurs seulement par exemple...) qu'un service étatsunien avait approché dans son dos un de ses ingénieurs, d'une part pour se renseigner sur les projets opensource utilisés dans Telegram, d'autre part pour inciter à utiliser certains outils opensources. Dommage qu'il ne donne pas les noms mais il devait y avoir quelque chose autour de la sécurité de ces bibliothèques et outils qui arrangeait les services de l'empire.